1. Field of the Invention
The present invention relates to the management of information handling systems. More specifically, embodiments of the invention provide a system, method, and computer-readable medium for perpetuating a system's entitlement to digital assets when the system's components are replaced.
2. Description of the Related Art
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
In recent years, it has become common for manufacturers to offer standardized configurations of these systems bundled with an operating system (OS) and a selection of software applications, digital content, and associated services. Some of these same manufacturers also offer purchasers the ability to order a system custom-configured to their specification. These custom-configured systems, which are often ordered on-line, allow the purchaser to select the OS of their choice along with a selection of software and other digital assets to meet their individual needs. In some cases, the manufacturer may preinstall the OS and the selected digital assets on the system prior to delivery. In addition, the system may be further personalized (e.g., desktop themes and colors, etc.) as a service to the customer.
It is also common for such systems to comprise a unique identifier (ID), often referred to as a service tag, which may be an one, or a combination, of motherboard, processor, or other system component serial numbers or IDs. It is likewise common for digital assets to be bound to these unique IDs as they are being installed on the system for protection against illegal copying. However, approaches are known to spoof these unique IDs, which circumvent the aforementioned copy protection. Furthermore, this association may create issues as the binding between the unique ID and digital assets will become broken if one or more system components fail or are replaced. As a result, the digital assets will typically need to be re-bound (i.e., reassociated) with the new unique ID resulting from the new ID of the replaced component(s).
Current approaches to this issue include binding digital assets to a Trusted Platform Module (TPM), which provides hardware-based security. However, TPMs are generally not implemented on consumer grade systems. Alternatively, the user may contact the vendor of the digital assets, provide the new unique system ID, assuming they are able to access it, and request a new binding between the digital assets and the new ID. As yet another alternative, the user may uninstall the digital assets and then reinstall them. However, this approach may also require contacting the vendor of the digital assets. These processes are typically tedious, error-prone, and can significantly increase the amount of time it takes to restore the functionality of a digital asset after replacement of a system component. In view of the foregoing, there is a need for a more secure unique system ID that both allows the binding of digital assets to be transparently transferred when system components are replaced and does not require the use of a TPM.